http://bit.ly/jmb-idm2014 http://jmbhome.herokuapp.com/teaching/idm2014/main.html http://jmbhome.herokuapp.com/teaching/idm2014/main.slides.html
git clone https://github.com/jmbruel/idm2014
Tool for defining UML-based DSLs
More details:
People from CEA-List involved in this case study (special thanks):
Project involvment (3.5 days):
Process:
Abstract syntax for a new language
Starting from the expected DSL (most of the time a modelsc or a graphical
représentation) and a description of the domain model (modelmde)
A domain modelmde is more precisely defined (e.g. a class diagram such as [mm1])
The concepts (e.g., Farm in [mm1]) are mapped to the
more suitable UML elements (e.g., Class in [profile1])
If the concepts directly match UML concepts (or if there is a way to slightly modify them so that they match) then it is possible to define a profile. (see e.g., [profile1])
Else another solution (e.g., defining a metamodel from scratch) should be studied.
It is time then to "customize" the DSML to make it as close as possible as the user domain representation.
|
|
There are different ways of defining the domain model:
|
The above process is iterative. The constructs are introduced by step.
The profile is experimented in a modelsc importing the profile so that the user can validate
that the concepts are captured adequatly.
This is were the UML expert can use tuning possibilities.
The next steps can consist in:
Working on the concrete syntax:
|
|
|
Let us illustrate the need for a specific concrete syntax.
using the profile in examples
period in this figure)
Using ecore
In the UML profile approach
the assumption is that their is a benefit in having both additional concepts and tooling, notably in terms of
Document réalisé par Jean-Michel Bruel via Asciidoctor (version 1.5.1) de 'Dan Allen', lui même basé sur AsciiDoc.
Pour l’instant ce document est libre d’utilisation et géré par la 'Licence Creative Commons'.
licence Creative Commons Paternité - Partage à l'Identique 3.0 non transposé.
Photo credits:
/